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An  Object  Oriented  Programming  Environment  for 
Communication,  Coordination  and  Control  in  Computer 
Intergrated  Design  and  Construction:  Phase  I 


Abstract 

The  development  and  testing  of  knowledge  based  ctunputer  tools  for  the  integration  of  design  and  construction 
(CIDCIS)  are  described.  A  system  architecture  is  presented  which  is  intended  to  provide  coordination  among 
multiple  designen  working  in  separate  engineering  disciplines,  using  knowledge  to  estimate  interface  conditions 
between  disc^lines,  recording  who  used  any  piece  of  design  data  created  by  others,  and  how  such  data  was  used, 
and  for  conflicts  among  disciplines,  constructability,  and  construction  cost  and  schedule  impacts  of  design 

<j«:igiftn<e.  The  system  is  based  on  the  object  oriented  programming  and  blackboard  control  techniqoes.  Cwrent 
status  of  CIDCIS  along  with  a  simulation  example  is  presented. 

1  Introduction 

On  July  17, 1981,  two  skywalks  in  the  lobby  of  the  Hyatt  Regency  Hotel  in  Kansas  City  collapsed.  Cited  as  the 
"most  devastating  structural  coUs^  ever  to  take  place  in  the  United  States",  113  people  died  and  186  were  injured 
[11].  This  was  not  only  a  failure  of  a  physical  structural  system,  but  also  a  failure  of  the  process  by  which  mos: 
projects  in  the  U.  S.  are  designed  and  built  The  primary  objective  of  our  research  is  u>  provide  computer  based 
tools  which  would  help  during  design  and  construction  to  avoid  errors  of  the  t^-pe  made  in  Kansas  City. 

The  Hyatt  failure  was  attributed  to  a  combination  of  three  events.  First  in  progressing  from  the  preliminary  to 
detailed  design,  where  joint  atxl  connection  detailing  occurs,  the  design  of  the  hanger  to  spandrel  beam  connection 
was  inadequate.  Second,  in  developing  shop  drawings,  the  connection  detail  was  changed  by  the  steel  &bricator, 
thereby  "compounding  an  already  critical  condition."  Tltird,  this  second  error  was  not  caught  during  approval 
checking  of  the  shop  drawings  by  the  structural  engineers.  These  were  aU  errors  of  communication  and  coordinaiion 
in  the  design  inocess,  errors  caused  by  the  structure  of  the  process,  lack  of  tools  used  in  this  process,  and  focus  on 
documenting  the  product  of  design  while  neglecting  "process"  and  "intent"  documentation. 

Construction  creates,  in  general,  one-of-a-kind  products  which  are  unique  configurations  of  widely  used 
components.  The  planning  process  is  a  tyincal  configuration  type  process.  Because  of  the  large  number  of 
components  and  the  iiueractions  of  multiple  technologies,  the  components  included  in  the  product  are  decided  in  an 
iterative  design  process.  In  each  iteration,  interfaces  and  interface  conditions  among  these  components  an*  designed 
with  slack  to  account  for  potential  variations  created  when  the  components  and  interface  values  become  better 
known.  Iteration  proceeds  towards  increasing  detail;  design  personnel  may  change,  and  their  numbers  expand  with 
increasing  level  of  deiiiL 

Construction  in  the  U.  S.  is  fragmented.  On  a  single  project,  interacting  design  technologies  come  from  separate 
firms,  and  there  is  little  coordination  between  designen  and  contractorfs).  Because  designers  find  coordination 
among  themselves  difficult,  they  leave  this  task  to  construcrioomanagen  or  the  contractor.  Thus,  working  drawings 
lack  detail  Shop  or  frdrrication  drawings  are  required  to  document  details,  but  potential  conflicts  among  trades  are 
often  unrecognized  until  construction  begins.  Several  undesirable  effects  are  caused  by  this  lack  of  coordination. 

1.  The  consiruction  process  is  slowed,  work  stops  when  a  oonflia  is  found. 

2.  Prefabrication  opportunities  are  limited,  because  details  must  remain  flexible. 

3.  Ontortunities  for  automaticm  are  limited,  because  capital  intensive  high  speed  equipment  is 
incompatible  with  work  interruptions  from  field  recognized  conflicts. 

4.  Rework  is  rampant,  because  field  recognized  crmflicts  often  require  design  and  field  changes. 
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5.  Conservatism  prevades  design,  because  designers  i»t)vide  excessive  slack  in  component  interfaces  to 
avoid  conflict. 

6.  The  industry  is  unprepared  for  the  advent  of  automated  construction,  as  the  need  for  experience  in 
design  limits  choice  to  available  materials  placed  by  hand. 

All  of  these  problems  decrease  productivity.  In  addition,  failures,  such  as  the  Hyaa  collapse,  occur  more  often  then 
they  should.  Overcoming  these  problems  requires  significant  changes  to  the  design  process,  together  with  superior 
computer  integrated  construction  (CIC)  tools.  Those  tools  must  be  tailored  to  the  needs  of  designers  who  are  [2]: 

’‘ccmstantly  engaced  in  teaichina  out  vsious  consequence*  of  design  dedsioiis  (especially  those  made  by  othen]* 

This  rqxm  details  the  development  of  a  prototype  system  to  test  new  concepts  for  computer  tools  to  integrate 
design  and  construction.  The  major  objectives  of  our  research  are  to: 

1.  Acilitate  effective  coordination  and  communication  in  design  and  construction. 

2.  Cepum  the  process  by  which  individual  designers  make  decisions,  that  is,  what  information  was  used, 
how  it  was  used  and  what  did  it  create. 

3.  Forecast  the  impact  of  design  decisions  on  construction. 

4.  Provide  designers  interactively  with  detailed  consmiction  plarming. 

5.  Develop  intelligent  interfaces  for  automation. 

Our  framework  for  a  computer  integrated  design  and  construction  system  (CIDCIS)  could  significantly  improve, 
productivity  by, 

•  reducing  error  in  design; 

•  providing  more  detailed  design; 

•  providing  better  construction  planning; 

•  allowing  easier  recognition  of  design  and  construction  problems; 

•  using  construcubility  criteria  throughout  design;  and 

•  advancing  automation. 

Lessons  from  the  Hyatt  failure  show  that  such  tools  are  required.  Had  the  connection  designer  had  access  to  the 
concepts  of  load  transmission  underlying  the  preliminary  design,  local  buckling  might  have  been  recognized  and  the 
joint  details  changed.  Had  the  fabricator  preparing  the  shop  drawings  had  access  to  that  information,  he  would  have 
seen  that  his  change  violated  the  purpose  of  the  connection  scheme.  Had  the  shop  drawing  checker  seen  all  these 
changes  together  with  their  intent  and  known,  he  would  have  recognized  the  faults  in  the  design. 

Ihe  engineeiitif  design  process  and  proUems  associated  with  this  process  are  described  in  Section  2 .  Using  this 
background,  an  overview  of  the  proposed  product  of  this  work  is  given.  BackgroutKl  material  on  computer-based 
technologies  used  in  this  work  is  presented  in  Section  3.  A  system  architecture  which  utilizes  concepts  from 
knowledge-based  systems  and  database  management  systems  is  described  in  Section  4.  This  is  followed  by  a 
descrqMion  of  the  current  stanis  of  die  project  and  a  list  of  publications. 

2  Scope  of  Work 

The  probkins  that  engineers  normally  solve  Gdl  along  the  derivation-formation  spectrum  [1].  In  derivation-type 
proUems,  solutions  consist  of  identifying  an  outcome  or  hypothesis  from  a  finite  set  of  outcomes  known  to  the 
proUem  solver.  By  contrast,  in  formation-type  proUems,  the  problem  solver  has  only  the  knowledge  of  how  to 
form  the  solution.  A  variety  of  problem  solving  techniques  are  invoked  to  arrive  at  a  solution. 
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Design  and  construction  planning  problems  fall  at  the  formation  end  of  this  spectrum.  Design  and  Planning  are 
accomplished  by  a  team  of  engineers,  each  knowledgeable  in  a  particular  aspect  of  the  problem,  but  with  little 
knowledge  of  the  decision  processes  of  others.  Each  could  be  considered  as  one  of  many  sources  of  knowledge,  and 
heitce,  design  and  construction  could  be  viewed  as  a  process  of  constructing  an  artifact  which  satires  constraints 
from  many  sources  by  using  knowledge  which  also  comes  from  many  sources.  The  extent  of  interactions  can  be  seen 
by  kxridng  at  the  diverse  set  tasks,  listed  in  Table  1,  that  must  be  performed  by  a  diverse  set  of  professionals  during 
the  design,  for  example,  for  a  high  rise  building  [14]. 


Planning 
Spatial  layout 

PKliminary  structural  design 
Component  desi^ 
Subnructure  design 
Electrical  distribution  design 
Mechanical  design 
HV  AC  design 

Vertical  transportation  design 
Various  design  critics 


Architectural  design 
Site  plaruiing 
Aitalysis  modeling 
Geometric  modeling 
Cost  estimating 
Elect  distribution  analysis 
Mechanical  analysis 
HVAC  analysis 
Regulatory  compliance 
Fire  safety  analysis 


Table  1:  Tasks  involved  in  the  Design  of  a  Tall  Building 

As  CAD/CAE  becomes  more  widespread,  each  of  these  consultants  will  be  performing  increased  amount  of  their 
work  with  computer  tools,  tools  which  will  embody  and  use  their  knowledge  in  their  speciality  area. 

From  this  view,  the  stages  of  structural  design  and  construction  might  be  described  as  [15]: 

1.  Conceptual  design  involves  the  selection  or  synthesis  of  a  potential  (prelimiiuuy)  design  satisfying  a 
few  key  constraints. 

2.  Analysis  is  the  process  of  modeling  the  selected  system  and  determining  its  response  to  external 
effects. 

3.  Detailed  design  is  the  selection  and  proportioning  of  components  such  that  all  applicable  constraints 
are  satisfied. 

4.  Design  Review  involves  evaluation  of  the  detailed  design,  produced  above. 

5.  Construction  involves  the  preparation  of  shop  drawings,  development  of  detailed  construction 
schedules,  actual  construction,  and  construction  monitoring. 

During  each  stage  in  this  process,  representatives  from  the  various  interacting  disciplines  meet  and  discuss 
potential  interactions  between  the  components  they  are  designing.  They  use  estunates  of  space  needs,  structural, 
heat,  and  electrical  loads,  and  other  factors  to  set  lequireineats  for  their  systems  based  on  the  needs  of  others. 
Experience  is  used  to  estimate  these  interfaces.  Explanations  on  how  these  estunates  were  determined  is  seldom 
sought,  excqx  where  diey  cause  conflicts  between  objectives.  When  individual  designen  select  components  and 
systems  during  any  stage  of  design,  they  use  and  try  to  develop  striutions  which  satisfy  the  interface  estimates. 

The  problem  with  this  process  is  that  individual  designers  often  lack  sufficient  experience  in  both  estimating  their 
interflKes  (assessing  their  impaa  on  others)  and  in  addng  Cor  information  needed  from  others.  They  assume, 
instead,  sttuadoas  similar  to  other  designs.  Similarly,  diey  seldom  think  about  and  may  even  lack  knowledge  of 
consuuctabili^  or  management  and  control  trf  the  construction  process.  This  may  lead  U)  incompatible  component 
selection  and  poor  choice  of  design  parameters.  For  example,  the  use  of  wide  rooms  in  low  cost  housing  is 
incompatible  with  inexpensive  construction  techniques.  The  designer'  is  assumed  in  this  process  to  have  sufficient 
knowledge  of  construction  techniques,  materials,  and  equipment  to  make  proper  decisions.  This  is  seldom  the  case. 
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Also,  since  the  present  design  process  does  not  document  reasons  behind  decisions,  others  cannot  easily  question 
decisions  or  improve  designs. 

In  this  report  we  will  provide  a  conceptual  framework  for  a  computer-based  system  that  addresses  the  above 
problems.  Figure  1  provides  a  user  view  of  a  COCIS  (Computer  Integrated  Design  and  Construction  System), 
where  users  within  their  discipline  interact  with  individual  CAD  tools  and  KBS  for  component  design  and  solution 
gitnfjMinn  These  systems  automatically  communicate  with  a  global  system  which  provides  data  and  support 
facilities. 


Figure  1:  Usa  View  of  QDQS 

In  the  first  version,  we  plan  to  use  two  interacting  computers,  one  operating  with  a  commercial  CAD  system,  the 
other  a  high  speed  workstation  with  good  knowledge  representation  tools.  Knowledge  represemaaons  for  support 
facilities  are  required  to; 

1. Esdmate  and  negotiate  interface  parameters  between  stages  of  design,  doing  so  in  an  interactive 
manner,  when  a  designer  asks  for  information  (ix..  if  a  designer  asks  for  information  that  has  not  yet 
been  devdoped,  knowledge  will  be  used  to  estimate  values); 

2.  Keqi  track  of  who  used  design  information,  when,  and  whether  it  was  estimated  or  actual  values  (so 
that  when  values  change,  the  design  can  remain  coordinated); 

3.  Use  coded  individual  knowledge  sources  to  assist  in  or  automate  component  design,  retaining 
component  information  about  sources  of  data  used  in  the  design,  the  algorithms  or  knowledge  used, 
and  inputs  on  design  rationale  from  the  user, 

4.  Operate  numerous  background  processes  to  chedc  design  choices  for  interferences,  violations  of 
interface  assumptions,  constructability,  and  cost  and  schedule  impacts; 

5.  Allow  user  input  aiKl  design  alterations  from  either  die  CAD  system  or  the  krxiwiedge  rqrresentation 
wwkstation;  and 

6.  Inform  designers  of  the  impacts  of  initial  designs  and  changes  by  othen  on  their  design  choices. 
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Development  of  this  system  involves  solutions  and  integration  of  the  following  basic  requirements  for  managing 
the  complexity  of  engineering  design  knowledge  and  data  [10]. 

1.  Hierarchical  knowledge/data  structure. 

2.  (%j6ct  oriented  representations, 

3.  A  mechanism  that  keeps  tracks  of  design  and  plaiming  justifications. 

4.  Multiide.  correlated  design  requirements. 

5.  Cross  representation  consistency  checking. 

6.  Version  connoL 

7.  Keeping  track  data  use. 

8.  Programming  language  interfaces. 

9.  Interaction  with  graphics  and  drafting. 

10.  Conventiona]  dataha.ses  and  analysis  tools. 

1 1.  Integration  with  consuuction  (manufacturing)  project  management  data. 

A  framework  that  addresses  most  of  the  above  issues  is  described  in  Section  4. 

3  Background  on  Computer ‘Based  Technologies 

Several  computer-based  technologies  required  for  this  work  work  are  briefly  described  in  Sections  3.1  and  32. 


3.1  Relevant  Computer-Based  Technologies 

Devek^ments  in  computer  science  and  engineering  methodotogies  have  provided  engineers  with  a  variety  of 
software  development  tools.  The  computer-based  software  development  tools  that  are  relevant  to  this  project  are: 

1.  Object  Oriented  Programming  (OOP)  Methodologies; 

2.  Knowledge  based  systems  (KBS); 

3.  Database  management  systems  (DBMS);  and 

4.  Traditional  algorithms. 

Object  Oriented  Programming.  Objea  Oriented  Programming  (OOP)  is  a  style  of  programming  that  involves 
the  use  of  objects  and  messages.  Objects  are  deflned  by  Stefik  and  Bobrow  as  [19]: 

Objects  are  entities  that  combine  the  properties  of  procedures  and  data  since  they  perform  compuutions  and  save  local 

stile. 

Ejects  contain  slots  and  slots  may  consist  of  a  number  of  facets.  A  slot  may  simply  be  an  attribute  or  it  may  be  a 
relation.  The  fimett  contain  meta-information  about  the  slot 

An  actions  in  object  oriented  pfogramming  are  performed  through  messages.  Messages  tell  the  object  wfiat  to  do 
and  not  how  to  do  it.  Methods  are  attached  to  the  object  to  execute  the  actions  associated  with  the  messages.  The 
message  passing  Ability  in  OOP  supports  the  concept  of  data  abstraedon. 

Objects  can  be  grooped  into  "classes,"  where  each  class  of  objects  knows  bow  to  perform  several  actions. 
Indivkhial  insfices  of  objects  can  be  created  from  a  particular  class.  The  Object  Oriented  programmer  builds  a 
system  by  specifying  new  classes  of  objects  and  their  associated  methods.  Most  OOP  systems  support  the  concept 
of  "inherituice,"  where  a  class  of  objects  may  be  specified  as  a  "subclass"  of  another  "superclass"  of  objects. 
Subclasses  and  instances  inherit  methods  from  their  superclass,  and  are  usuaUy  more  specific  entities  than  their 
(usually)  more  general  superclass.  An  object  may  inherit  m«bods  and  daa  from  muldi^  classes  through  a  network 
of  stmcnml  relationships.  In  short,  every  object  has  the  ability  to:  store  irtformation,  process  uiformahon,  create 
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new  information,  and  communicate  with  other  objects.  Thus  OOP  facilitates  encoding  design  and  construction 
knowledge  in  a  disaggregated  and  modular  form. 

As  an  example  consider  the  following  object 


BEAM-1 

Inatanc*:  "team” 

M  : 

Mathoda:  Dlsplay-momant,  Caleulata-momaat 


The  message  (send  beam-1  calculate-moment),  where  bemn-1  is  the  object  to  which  the  message  is  addressed, 
would  compute  the  moment  in  arcordance  with  the  Calculate-monent  method.  For  further  details  about  object 
orioited  programming  see  [19]. 

Knowledge-based  systems.  KBS  are  computer  programs  which  incorporate  knowledge  and  reason  through  the 
qrplicatiop  of  their  knowledge  to  data  about  a  specific  problem.  If  these  systems  incorporate  human  expertise  then 
they  are  called  knowledge-based  expert  systems  (KBES).  For  the  purpose  of  this  proposal,  the  term  KBS  will  also 
be  used  to  connote  KBES.  A  typical  KBES  consists  of  three  components;  Knowledge-base,  Context,  and  Inference 
Mechanism  or  Control  Mechanism.  Several  problem  solving  architectures  used  in  the  Inference  Mechanism  are. 
described  in  [18].  In  this  work,  a  variation  of  the  Blackboard  architecnire.  which  facilitates  the  integration  of 
diverse  sources  of  knowledge  through  a  global  database  •  the  Blackboard,  will  be  used  [6].  A  brief  description  of  the 
Blackboard  architecture  is  provided  in  the  next  section.  In  addition,  the  work  on  truth  maintenance  systems  will  also 
be  utilized  [3, 4]. 

Database  nunagement  systems.  Engineers  have  always  dealt  with  large  amounts  of  data  iii  diverse  applications. 
Hence,  suxing  and  manipulating  data  forms  an  integral  pan  of  the  engineering  process.  Database  management 
systems  (DBMS)  provide  means  to  store  large  amounts  of  data  for  use  by  a  variety  of  qrplications.  Data  access  is 
controlled  through  a  dictionary  so  that  individual  programs  need  not  be  changed  when  the  datahase  structure 
changes. 

A  number  of  systems  that  utilize  some  of  the  computer-based  technologies  and  relevant  to  the  proposed  work  are 
described,  in  the  following  sections. 


32  Blackboard  Architecture  &  Relevant  Systems 

The  Blackboard  architecture  provides  a  bamework  for  1)  integrating  knowledge  born  several  sources,  and  2) 
rqxesenting  multiple  levels  of  problem  decompositioa  It  uses  two  basic  stiai^es  [12]:  1)  divide  and  conquer,  and 
2)  opportunistic  problem  solving.  The  divide  and  conquer  strategy  is  realized  by  decomposing  the  context,  which  is 
called  a  Blackboard,  imo  several  levels  depicting  the  problem  lolutioo  decomposition,  while  opportunistic  problem 
solving  is  achieved  by  focusing  on  the  partt  of  die  problem  that  seem  promising.  The  Blackboard  architecture  has 
been  successfully  used  in  solving  a  wide  range  of  tasks,  such  as  qieedi  recognition  [5],  signal  processing  [13],  and 
planning  [6].  In  this  section,  an  overview  of  the  Blackboard  architecnire  is  presented^ 

A  Blackboard  system  consists  of  a  number  of  Knowledge  Sources  that  communicate  through  a  Blackboard  and 


‘The  eiticle  by  Penny  Nii  in  the  Sinnincr  1986  isnie  of  the  AI  MtfuiDe  prrvidce  c  good  overview  and  nrvey  of  eevenl  Bledcboaid  based 
KBES. 
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Figure!:  The Blackbotrd Architecture 
(Adapted  from  [7]) 
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are  controlled  by  an /n/irrence  Mec/uinum,  as  shown  in  Figure  2.  These  components  are  described  below. 

KnowIcdgC’Base.  The  Knowledge-base  consists  of  a  number  of  knowledge  sources  (KSs).  These  KSs  are 
independent  clunks  of  knowledge  and  do  not  directly  communicate  with  each  other.  Instead,  they  participate  in  the 
problem  solving  process  by  creating  entries  in  a  global  database  -  the  Blackboard.  Each  KS  consists  of  a  condition- 
actioo  pair.  When  the  conditions  of  a  particular  KS  ate  stiisfied  the  KS  is  traced  on  an  agenda  in  the  Inference 
Mechanism.  The  actions  of  the  KS  are  executed  when  the  KS  becomes  executaUe,  ix.,  it  has  a  high  priority  rating. 
KSs  can  also  be  organized  into  larger  chunks  called  knowledge  modules  (KMs).  The  knowledge-base  can  be  further 
organized  into  various  levels,  as  shown  in  Figure  2:  this  organization  was  first  implemented  in  HASP/SIAP  [13]. 
These  levels  depict  a  plan  for  organizing  |»oblem  solving  activittes. 

Blackboard.  The  Blackboard  or  Context  consists  of  the  information  or  entries  generated  by  the  KSs  during  the 
problem  solving  process.  It  is  organized  into  a  number  of  levels.  These  levels  depict  an  a  priori  plan  for  the  solution 
of  a  problem  that  can  be  naturally  decomposed  into  a  set  of  levels.  Each  level  contains  objects  and  attributes  that  are 
important  to  the  representation  of  the  problem.  The  hierarchy  of  levels  in  the  Blackboard  is  known  as  die  abstraction 
hierarchy. 

In  addition  to  the  vertical  abstraction  hierarchy,  the  Blackboard  can  also  have  a  horizontal  dimension.  For 
example,  in  HEARSAY-II  and  0PM.  the  horizontal  dimension  represents  overlapping  intervals  in  the  solution. 
N(»TnaUy.  KSs  are  specific  to  certain  levels  in  the  Blacdtboaid.  ie..  the  activation  of  a  certain  KS  depends  on  the- 
entries  generated  at  certain  levels  in  the  Blackboard,  while  the  actions  of  the  KS  modify  entries  at  some  other  level. 

The  main  units  in  the  Blackboard  are  hypotheses.  TIm  hypotheses  are  either  primary  guesses  about  particular 
aspects  of  the  problem  or  partial  solutions.  Hypotheses  at  various  levels  are  related  through  structural  relationships. 

Inference  Mechanism.  The  control  strategy  incorporated  in  various  Blackboard-based  systems  differ  in  many 
aspects.  In  the  earlier  versions  of  Blackboard  systems,  the  Inference  Mechanism  consisted  of  two  main  components: 
the  Agenda  or  Scheduler,  and  the  Monitor.  The  Agenda  keeps  track  of  all  the  events  in  the  Blackboard  and 
calculates  the  priority  of  execution  for  KSs  that  were  generated  as  a  result  of  the  activation  of  other  KSs.  The 
Monitor  takes  the  element  with  the  highest  priority  and  executes  it  Several  problem  solving  strategies  can  be 
implemented  using  the  Agenda  and  the  Monitor.  The  Inference  Mechanism  described  above  was  further  elaborated 
in  several  Blackboard-based  KBES. 

A  summary  of  current  Blackboard-based  rystems  is  provitfed  in  Table  2.  Further  information  about  these  systems 
can  be  found  in  [9]. 

4  A  Framework  for  Computer  Integrated  Design  and  Construction 

In  Section  1  (page  2}  several  objectives  for  a  Computer  Imegraied  Design  and  Construction  System  (ODDS) 
have  been  enmnented.  To  achieve  these  goal,  a  system  architecture  based  on  current  trends  in  fvogiamming 
methodologiet,  dbjea  oriented  databases,  and  knowledge  based  systems  is  described.  An  overview  of  a  QDCIS  is 
provided  in  Section  4.1.  This  is  followed  by  a  discussioo  of  various  components  comprising  die  system. 

4.1  Overview  of  CIDCIS 

CIDCIS  cr~  be  eavisimed  as  a  netwoik  of  computers  and  users,  where  the  communication  and  coordination  is 
achieved,  through  a  global  database,  by  a  control  mechanism.  CIDQS  consists  of  several  Knowledge  Modules,  a 
Blackboard,  and  a  Control  Mechanism.  These  terms  ate  clarified  below. 

1.  Control  Mechanism.  The  communication,  coordination,  data  mnsfer,  and  all  other  functions  define 
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Table  2:  Sutnninry  of  Various  Blackboard  Sysicms 
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the  Control  Mechanism.  Sometimes  this  control  mechanism  is  also  known  as  Inference  Mechanism. 

2.  Blackboard.  The  medium  through  which  all  communication  takes  place.  The  Blackboard  in  the 
proposed  system  is  divided  into  three  partitions:  Coordination,  Solution,  and  Constraint  Definition. 

The  Solution  Blackboard  partibon  contains  the  design  and  construcbon  inftxmauon  generated  by 
various  Knowledge  Modules,  most  of  which  is  referred  to  as  the  Obj^  Hierarchy  containing 
infonnabon  about  the  design  produa  and  process,  while  the  Constraint  Definioon  Blackboard  partition 
contains  the  interacbon  (or  interface)  constraints  between  objects  depkbng  various  components  of  the 
design  and  construcbon  process.  The  Coordination  Blackboard  parbbon  will  contain  the  infnmabon 

for  the  coordination  of  various  Knowledge  Modules. 

3.  Knowledge  Module.  A  Knowle^e  Module  can  be  viewed  either  as:  a  knowledge  based  expert 

system,  developed  for  solving  individual  design  and  construcbon  related  tasks,  or  a  CAD  tool,  such  as 
a  stfucture,  i.e.,  a  specific  database,  an  analysis  program,  etc.,  or  an  user  of  a  computer,  or  a 

combination  of  the  above.  A  KBES  could  be  viewed  as  an  aggregation  of  Knowledge  Sources  (KSs). 

Each  KS  is  an  indq)endent  chunk  of  knowledge.  rqMtsented  either  as  rules  or  objects.  In  die  proposed 
system,  the  KnowMge  Modules  are  grouped  into  three  categnies:  Strategy,  Specialist,  and  Resource, 
ihe  Strategy  KMs  heh>  the  Conuol  Mechanism  in  the  coordination  and  commuiucabon  i^ocess.  The 
Specialist  KMs  perform  individual  specialised  tasks  of  the  design  and  construction  process,  while  the 
Resource  KMs  are  mosby  algorithmic  CAD  tools. 

A  conceptual  view  of  a  CIDCIS  is  shown  in  Figure  3.  In  it.  any  of  the  KMs  can  make  changes  or  request 
infeamabon  from  the  Blackboard:  requests  for  informabon  are  logged  with  die  objects  represenbng  the  infonnabon; 
and  changes  to  the  Blackboard  may  inibate  either  of  the  two  acbons:  finding  the  implicabons  and  nobfying  various 
KMs,  and  entering  into  a  negobabon  p'oeess,  if  two  or  more  KMs  suggest  confliebng  changes. 

Details  of  individual  components  are  provided  in  the  following  seebons. 


4  J  Control  Mechanism 

The  Control  Mechanism  performs  two  tasks:  1)  evaluate  and  propagate  implicabons  of  acbons  taken  by  a 
particular  KM;  and  2)  assist  in  the  negobabon  process. 

Ta^  1  is  accomplished  through: 

1.  methods  associated  with  objects  in  the  Object-Htererchy  of  the  Solubon  BlacUxiard  panition  (SBB); 
and 

2.  a  truth  mairuenance  system  which  ke^  the  global  database  in  a  consistent  state. 

If  two  KMs  try  to  access  the  same  object,  then  the  priorities  are  achieved  by  the  Strategy  KM  and  the  scheduling 
infcvmabon  is  stored  in  the  Coordinabon  Blackboard  parbbon  (CORDBB).  A  possible  trace  of  events  is  shown  in 
Figure  4,  and  outlined  below. 

1.  A  preUminary  design  of  a  building  (in  the  form  of  objects)  which  includes  loading  details  and 
designer's  intenbons  in  making  certain  decisioos  is  posted  on  to  the  Solution  Blackboard  partibon  by 
the  Concqitual  Designer. 

2.  Let  the  connection  details  of  a  parbcular  joint  be  repreaenied  by  the  Conneebon  object.  The 
Connectioo  Designer  win  send  a  message  with  details  of  oormeebons  and  any  assumpbons  made 
during  the  design. 

3.  The  truth  mahuenance  system  checks  to  see  whether  eariier  assumpbons  made  by  the  ConcqKual 
Designer  are  violated  or  not 

4.  Assodaied  with  the  Conneebon  objea  are  methods,  which  indicate  die  possible  KMs  that  can  modify 
the  object.  Assume  that  Fabricate’  KM  is  me  of  than.  A  message  is  sent  to  Fabricator  KM  to  fuid  out 
wbetha  the  connection  can  be  fabricated  in  the  field. 

5.  Notify  the  Conneebon  Designa  if  any  problems  are  anbeipated. 

6.  Sometimes  two  or  more  KMs  may  want  to  modify  or  access  a  particular  object  in  the  Solution 
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ri{urc  3;  A  Conceptual  View  of  CIDCIS 


User _ II  I  I  User  |  |  |  |  User 

Note:  User/CAO  Interlace  is  optional  in  KMs 
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Blackboard  partition.  This  information  is  stored  in  Coordination  Blackboard  partition  and  is  used  by 
the  Control  Mechanism. 

A  possible  scenario  for  task  2  for  a  domain  which  involves  the  design  and  construction  of  interior  finishes  is  given 
below  (See  Figure  S). 

1.  Let  the  Architectural  KM  post  the  location  and  other  details  of  beams  in  the  beam  object,  whose 
primary  owner  is  Architectural  KM. 

2.  The  HVAC  (Heating.  Ventilating  and  Air  Conditioning)  KM  would  post  a  message  with  the 
assumption  thtt  there  is  a  hole  in  the  beam. 

3.  Solution  Blackboard  partition  sends  a  message  to  Constraint  Definition  Blackboard  partition,  which 
rtM»rk«  to  see  if  the  objects  being  modified  have  any  mteraction  (interface)  constraints.  If  so  then 
typrqiriate  constraints  are  stored  in  the  Coordination  BB  partition. 

4.  Solution  Blackboard  partition,  then,  sends  a  message  to  Strategic  KM  to  check  the  constraints. 

5.  Strategic  KM  sends  a  message  to  the  Constraint  Handling  KM  (CHICM).  CHKM  checks  to  see  if  the 
interaction  (interface)  constraints  are  satisfied.  If  so.  a  message  is  sent  to  Solution  Blackboard 
partition  and  appropriate  actions  are  taken  (step  6' 

6.  If  the  interaction  constraints  are  not  satisfied  then  the  Strategic  KM  performs  a  constraint  negotiation. 
Constraint  negotiation  may  in\  olve  relaxing  constraints  by  a  particular  KM.  If  constraint  negotiation 
fails  then  system  goes  into  a  deadlock  and  alerts  the  KMs.  Constraint  negotiation  can  be  performed  at 
several  levels.  In  the  current  system  it  will  be  assumed  that  refinement  of  levels  in  the  Solution 
Blackboard  partition  occurs  only  after  appropriate  interaction  (interface)  constraints  are  satisfied. 

7.  If  above  process  succeeds  then  Strategic  KM  sends  a  message  to  Solution  Blackboard  parution,  at 
which  stage  the  details  required  for  the  next  level  in  the  Solution  Blackboard  partition  are  set  up  and 
qjpropriate  KMs  are  activated. 


43  Blackboard:  Global  Database 

The  purpose  of  the  Blackboard  is  to;  1)  provide  a  means  for  storing  information  that  is  common  to  more  than  one 
KM:  2)  facilitate  communication  and  coordination;  and  3)  ensure  that  designs  and  plans  generated  during  design  and 
construction  ate  consistent. 

The  Blackboard  in  the  proposed  CIDCIS  will  be  partitioned  into;  Coordination  (CORDBB),  Solution  (SBB)  and 
Constraint  Definition  (CDBB)  (Figure  6). 

4  J.1  Coordination  Blackboard  Partition 

The  Coordination  Blackboard  partition  (CORDBB)  contains  the  bookkeeping  information  needed  for  the 
coordinatiao  of  KMs. 

433  Sohitioii  Blackboard  PartidoB 

The  Solutiaa  BB  portitioa  (SBB)  is  divided  into  levels  (object  hieiaichy).  Each  level  contains  objects  that 
lepieaem  certain  aspects  of  the  desip  and  constractioa  process.  For  example,  the  3D  space  level  contains  objects 
that  iqtresent  spaces  allocated  to  strucntral  systems,  piping  systems,  mechanical  systems,  etc.  This  level  can  be 
reduced  to  detailed  levels,  such  as  system  and  component  levels. 

The  otpcu  in  SBB  are  connected  through  relational  links,  where  the  relational  links  provide  means  for  objects  to 
inherit  information;  these  relationships  provide  a  framework  to  view  the  objea  fiom  different  perspectives.  In  this 
work,  the  following  relationships  are  needed  in  the  SBB:  generatization  f/S-A)  for  grouping  objects  into  class, 
ciassification  (INSTANCE)  for  defining  individual  elements  of  a  class,  aggregation  (PART-OF,  COMPONENT)  for 
combining  components,  alternation  (IS-ALT)  for  selectiry  between  alternative  concq)ts,  and  versionuation 
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1 1  I  I  I  I  I  I  I 

Mole:  User/CAO  Interface  Is  optional  In  KMs.  Also  messages  to  Interlace  Det.  are 
not  shown. _ .  - 


BLACKBOARD 


Figures:  The  Construnt  Negotiation  Process 


User  I  I  I  I  I  User _ |  |  |  |  |  User 

Note;  UserAI^AD  Intertace  is  optional  in  KMs.  Also  messages  to  Interlace  Del.  are 
not  shown. _ 
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Fi{iire<:  The  Blackboard 

(VERSION-OF)  for  rqjresenting  various  versions  of  an  object  The  semantics  of  these  relationships  are  provided  in 
flTJ. 

The  objects  contain  justifications,  assumptions,  time  of  creation,  creaiOT,  constraints,  ownership  KM,  other 
concerned  KMs,  etc.  The  justification  information  will  provide  a  designer’s  rationale  and  intent  for  the  creation  of 
the  object  Assumptions  made  during  design  and  construction  are  also  stored  with  the  object  For  example,  the 
*  architect  while  placing  the  structural  elements,  may  assume  certain  qtotial  characteristics  for  the  HVAC  systems. 
He  may  record  this  assumption  and  the  rationale  for  such  an  assumption  in  the  objects  denoting  the  appropriate 
structural  elements  and  the  HVAC  system.  In  CIDCIS,  Siam  facets  are  associated  with  data  attributes  (slots).  The 
Slam  facet,  for  example,  can  take  the  following  values:  unknown,  assumed  and  calculated.  Additional  slots  may  be 
needed  for  the  source  of  data  and  its  change,  uses  of  data,  assumptions  made,  etc.. 

Associated  with  these  objects  are  methods  which  provide  a  means  for  1)  performing  some  procedural 
raiqitotiftns;  2)  propagating  implications  of  performing  some  actions,  for  example  if  the  status  (assumed  or  actual) 
or  the  value  for  a  particular  Objea  changes  tten  these  changes  can  be  broadcast  to  all  concerned  KMs:  3)  helping  to 
perform  die  coordinatioa  process.  For  example  methods  can  be  used  as  demons  to  perform  the  following 
construction  relaiBd  tides: 

1.  Estimating,  which  involves  continuous  cost  forecasting  capabilities,  boro  early  estimates  toi  detailed 
costs  considering  the  equipment  that  wiO  be  avaOabie.  This  estimatiiig  wiO  start  with  material  and 
quantity  modelmg  based  on  budding  standards  for  lenam  work,  and  would  fust  be  updated  with 
characteristics  of  the  tenam.  As  layout  work  proceeds,  material  and  quantity  estimates  would  be 
updated. 

2.  Scheduling,  which  is  similar  in  structure  to  Estimating,  and  uses  much  of  the  quantity  data  developed 
from  the  esiimaie  forecast,  passed  to  it  with  messages. 

3.  Constructability,  where  constant  critics  kxdc  for  incompatible  materials,  qiace  use,  construction  space 
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needs,  equipment  requirements,  etc. 

Knowledge  for  ail  of  diese  inputs  will  come  from  working  with  expert  on  all  pi  -.ses  of  the  project,  owner,  designer 
and  consmictcff.  Further  details  of  the  use  of  methods  in  the  communication  process  are  provided  in  Section  4.2. 

A  typical  object  that  resides  in  the  SBB  could  be  structured  as  follows: 


SBB'Object 

loua: 

VUJn: 

status: 

caxann-BT: 

JDSTZrZCaTXOM: 

PJAT'OT: 

ZS-ALT: 

VEMZOW-^: 

VBtSZOK-aO: 

OWmO-BT: 

coMcnnxD-iws: 

CONSTMtZinS: 

range:  (XS-A  COMSTMIIMT-OBJECT) 
-  (and  so  on) 

NETBOOS: 


4  J  J  Constraint  Deflnition  Blackboard  Partition 

The  Constraint  Definition  BB  (CDBB)  contains  various  constraints  that  are  imposed  on  the  designed  object.  The 
constraints  can  be  of  two  types:  constraints  local  to  the  objea  (designed)  and  interaction  (interface)  constraints  that 
several  objects  should  satisfy  simultaneously.  An  example  of  a  local  constraint  is  Beam.bending-siress  should  be 
less  than  0.66*Beam.materkd.yield-stress,  while  the  example  of  an  interaction  constraint  is  Pipes  greater  than  2 
inches  cannot  go  through  steel  beams  or  columns.  Only  the  interaction  (or  interface)  constraints  will  exist  in  the 
CDBB;  the  local  constraints  will  reside  in  objects  of  individual  KMs. 

An  objea  describing  these  constraints  could  be: 


Constraint'Objcct 

COKSTIUtZaS: 

range:  (ZS-A  SB»-OBJCCT) 

ZMTiaaCTXW: 

status: 

range:  (IS-A  IMTEltACTIOM-COMSTItAIMT) 
otBBM:  (as  ruMdsd) 

MBxaoos: 


The  status  facet- can  take  values  like  sad^d,  suspended,  violated,  etc.  A  taxonomy  of  these  constraints  can  be 
defined  by  the  user.  Adequate  fiscilities  will  be  provided  for  the  user  to  incorporate  these  constraints.  For  further 
information  on  the  use  of  constraints  in  structural  design  see  [16]. 
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4.4  Knowledge  Modules 

The  Knowledge-base  (KB)  consists  of  a  number  of  Knowledge  Modules  (KMs).  Each  of  these  KMs  are  further 
decomposed  into  small  units  called  Knowledge  Sources  (KSs).  The  architecnire  of  most  KMs  could  be  very  similar 
to  the  overall  architecture  of  CIDCIS,  i.e..  knowledge  is  distributed  among  several  objects  (or  KSs)  and 
communicate  through  message  passing.  KSs  can  also  be  decomposed  into  smaller  units,  if  desired.  Taus  the  KB 
reflects  the  hierarchical  design  process. 

Some  KMs  may  incorporate  both  tenbook  and  heuristic  (surface)  knowledge,  while  odter  KMs  may  include /<uWy 
deep  knowledge.  Surface  knowledge  consists  mainly  of  production  rules  encoding  empirical  associations  based  on 
experience.  This  type  of  knowledge  is  useful  for  setting  interface  constraints  between  disciplines  and  between  levels 
of  design  interaction.  In  a  system  with  deq)  knowledge,  both  causal  knowledge  and  analytical  models  would  be 
incorporated.  A  fully  deep  system  may  be  difficult  to  realize  with  the  current  state  of  the  an  of  KBES.  However,  it 
is  possible  to  encode  aruJydcal  models.  In  this  study,  the  term  fairly  deq>  knowledge  is  used  to  denote  analytical 
models. 

The  KMs.  although  distributed,  can  be  classified  into  the  following  categmies:  Strategy,  Specialist,  and  Resource 
KMs.  These  KMs  are  briefly  described  below. 

•  Strategy  KMs  analyze  the  current  solution  state  to  determine  the  course  of  next  acbon.  A  scenario 
using  the  Strategic  KM  is  described  in  Section  6.2.  Since  this  level  may  used  to  control  various  tasks, 
such  as  the  activation  of  Specialist  KMs  during  the  coordination  process,  it  comprises  the  task  control 
knowledge. 

•  Specialist  KMs  contribute  to  various  stages  of  design  and  construction.  Most  KMs  at  this  level  are 
IfflES  that  have  a  local  Blackboard  which  may  be  divided  into  various  levels  abstraction,  and 
several  KSs  that  interact  with  the  local  BB.  For  example  the  possible  KMs  required  foe  an  interior 
finishes  design  and  construction  problem  are: 

1.  Archiusctural  Designer,  for  layout  and  finishes,  including  flooring  and  ceiling  systems,  etc. 

2.  HVAC,  for  heat  load  calculations,  duct  layout,  diffusers,  etc. 

3.  Lighting,  for  layout.  lighting  levels,  heat  generation,  etc. 

4.  Plumbing,  for  layout,  etc. 

5.  Construction  Planning,  for  schedules,  costs,  constructability  checking,  etc. 

6.  Structural,  only  for  detailing  attachments. 

Individual  KMs  will,  most  probably,  be  residing  on  different  machines  and  will  make  extensive  use  of 
netw<ffking  protocols  for  communicating  with  the  Blackboard. 

•  Resource  KMs  contain  die  analytical  knowledge  and  reference  information  required  for  analysis  and 
design.  These  KMs  are  ^ically  comprised  of  algorithmic  programs  and  databases.  Resource  level  KMs 
comprise  the  algori^ic  knowledge  of  the  domaia  Ibe  Specialist  KMs  mostly  communicate  with  die 
Resource  KMs  through  a  Blackbo^  diat  is  local  to  the  Specialist  KM. 

The  user  forms  aoioti^ial  part  of  these  KMs.  An  important  issue  in  the  development  of  KMs  is  the  man-machine 
imerfaoe  and  how  the  infannation  generated  by  the  user  is  transmitted  to  odier  KSs.  We  assume  that  the  user 
intecactt  with  the  cooqxitBr  through  a  high  resolution  bit  mqiped  diqilay  (or  qgjtopriaie  system).  Hence,  there  is  a 
need  to  provide  the  qipropriaie  semantic  translations  firm  the  infbrmatioo  provided  by  user  to  the  form  required  by 
odier  KMs  or  KSs.  In  the  proposed  system,  this  will  be  achieved  by  the  interface  definitioc  module.  Further  changes 
made  by  the  user  will  be  recorded  in  the  local  and  global  Blackboards  Of  needed)  and  appropriate  actions  triggered. 
Hence,  the  user  can  be  viewed  as  a  KS  taking  part  in  the  solution  process. 

The  KMs  (mosdy  Specialist  and  Strategy)  can  post  and  retrieve  infenmation  from  the  global  Blackboard. 
However,  an  object  (and  associated  attributes)  in  the  Blackboard  can  have  varied  cotuumkm  (most  semantic)  in 
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difleitm  KMs.  Hence,  there  is  a  need  to  define  the  semantic  mappings  (translations)  between  the  objects  in  the  KMs 
to  the  objects  in  the  Blackboard.  As  an  example,  consider  the  t^ject  Beam.  In  a  architectural  KM,  the  beam  may  be 
defined  as  follows  [8]: 


While  the  same  object  may  be  defined  in  a  HVAC  KM  as: 


Beam 

L-EMD: 

K-BID: 

D: 

TOE: 

HXmiAL: 

E'lMD-MaMEirti 

METBODS:  poasihla-cut-outs 


The  methodology  used  in  [8]  seems  promising  adapted  for  developing  the  necessary  semantic  translations  in 

ciDas. 
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5  Current  Status 

During  the  Hrst  year  of  the  project,  our  major  focus  has  been  the  development  of:  I)  utilities  for  defining  the  SBB 
object  hierarchy,  2)  transactions  for  posting,  modifying  and  deleting  information  from  the  Blackboard,  and  2)  a 
simulation  pix^gram  to  demonstrate  the  utility  of  CIDCIS,  which  is  being  implemented  in  a  hybrid  programming 
environment  called  FRULEKIT;  FRULEKIT  supporu  programming  in  frames  and  rules  and  was  developed  in  LISP 
at  Camegie-Mellon  University  by  Carbonell  and  Shell. 

These  topics  are  briefly  described  below. 


5.1  Graphic  Definition  of  Objects 

The  use  can  interactively  define  class  objects^  in  the  Blackboard  and  KMs.  Qasses  can  either  be  created  in  LISP 
or  thrxHigh  a  menu  interface  provided  to  the  user.  Eadi  class  has  a  name,  several  slots  which  describe  various 
attributes,  and  associated  with  each  slot  are  facets  which  provide  further  infonnation  about  the  slot;  the  facets  also 
contain  methods. 

A  class  object  is  created  by  clicking  on  CREATE<3jtss  in  a  menu  on  the  screen.  After  creating  a  class  object,  the 
user  can  display  the  class  using  the  DISPLAY^class  <^on.  as  shown  in  Figure  7. 


she  1  Hoot  lisp 


RESlOftE-ClASS 

SELECT-CLASS 

CREAZE-CLASS 

KM(E-SOPE3tCLASS 


SELECT-SLOT 
CREATE-SLOT 
RDtOTE-SLOT 
GIVE-SLOT-TAUIE 
SELECT-FACET 
CREATE-FACET 
REMOVE-FACET 
OlVE-FACEI-VALUE 
DISPUT-STATUS 
PUSH-PUT 
QUIT 


JCflitnu-crMta-claas) 

^Defining  class  BUILOl 

;;  Warning;  Rtdtflnlng  MAKE-BUILDI 
rMM  Class  F:6UILD1:  (:CACHE  C:%CUSS>  :IS-A  NIL) 


Figure?:  Displaying  a  Oan 

In  Figure  8.  the  class  Bnlldl  is  made  a  subclass  of  the  Hierarchj<<>bJect  class,  which  becomes  BuQdl's  stperclass. 
When  this  link  is  made,  all  the  slots  in  the  Hierarchj'Hrbjcct  class  are  inheriied  by  Bulidl.  In  addition,  the  user  can 
create  new  slots  or  delete  slots.  Fix’  example,  in  Figure  9  Uie  user  created  two  slots,  namely  name  and  has-parts. 


*A  dui  dwioMi  Sic  grouping  of  objeeu  Cntunee  or  dan)  wtiid)  have  timOar  dianaemiia,  while  an  innanoe  is  •  ptRtenlar  individutJ 
which  bdong s  to  a  date. ' 
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RESTORE-CLASS 

SELECT-CLASS 

CREATE-CLASS 


CREATE-SLOT 
RB40TE-SL0T 
CIVE-SLOT- VALUE 
SELECT-FACET 
CREATE- FACET 
REMOVE-FACET 

cive-facet-vau;e| 

DISPUY-STATUS 
PUSH- PUT 
CUIT 


ISSSSffiS99|i 

^ISnSl-CLASS 
SELECT-SLOT 


m 


she! Itool 


iDcflnlng  clast  BUILDl 

Warning:  Rsdsflning  MAKE-BUILDl 
iFrame  Class  /-.BUILDl:  (  -.CACHE  ( :XCLASS  :LINKED-TO-ROOT  XV. 
iPONCNTS  :PARENT  :X  :Y  :SPACE  ;P0STE0  :M0DIFIED  ;DELETED  -.HI 
ISTORy  :CURREN'r-SOLUTION)  :IS-A  (HIERARCHY-OBJECT;; 
|lIMKE0*T0-R00T  (.-value  nil  :DEP7h  2) 

tDEPTH  2; 

-.DEPTH  2; 

-.DEPTH 

: depth 
.-depth 

:DEPTH  1; 

: DEPTH  1; 

: DEPTH  1; 

: DEPTH 
: DEPTH 


ICOMPONENTS 

Iparent 


SPACE 

POSTED 

WOOIFIEO 

DELETED 

HISTORY 

CURRENT 

KMs;; 


( rVALUE  NIL 
( ;VALUE  NIL 
(:VALUE  NIL 
( ;VALUE  NIL 
(  VALUE  NIL 
( :VALUE  NIL 
( :VALUE  NIL 
(:VALUE  NIL 
(:VALUE  NIL 
SOLUTION  (rVALUE  NIL 


: CHANGEABLE  T; 
-.CHANGEABLE  T; 

.-changeable  t; 


1; 

1 


:PDST-IF-SET  (NOTIFY- 


w 


Figures:  Linking  a  Gass  to  its  Superclass 

Slots  can  be  faceted  or  nan-faceted.  Facets  slots  have  facets,  which  provide  further  information  about  the  sloL  The 
creation  of  facets  is  shown  in  Figure  10. 

Instances  of  a  class  can  either  be  defined  interactively  through  a  menu  or  can  by  LISP  functions.  For  example  the 
function  (creaie-insiance  'Buildl  ’Hyati-regency)  would  create  an  instance.  Hyatt-regency,  of  Buildl. 

In  addition  to  defining  classes  and  instances,  the  user  can  also  (iispiMy  the  class  hierarchy,  in  the  form  a  tree. 
Nodes  in  the  tree  depict  classes  and  instances.  Each  node  is  displayed  in  a  box  with  the  name  of  the  class  or 
instance.  If  the  name  does  not  fit  in  the  box  then  it  is  abbreviated.  The  user  can  drag  the  mouse  pointer  over  the  tree 
to  an  appropriate  node.  This  will  display  the  full  name  of  the  node  (Figure  1 1  a).  If  the  user  wants  more  detail  about 
the  node,  he  can  click  on  the  node  and  he  will  be  shown  the  slots  of  the  objea  corresponding  to  the  node  (Figure  1 1 
b).  Facet  information  for  any  slot  can  be  obtained  by  clicking  on  the  slot  (Figure  1 1  c). 

52  Bladcboard  Transactions 

Communicatioo  betweens  KMs  is  achieved  through  the  Blackbovd.  The  communication  channels  ate  estaNished 
in  special  slots  of  the  objea  hietarchy  in  the  SBB.  Whenever  a  new  KM  is  attached  to  GDCIS,  its  address  is  placed 
in  a  special  frame  in  the  Coordination  Blackboard  paniiiOR. 

Ctmently,  three  types  of  messages  can  be  aettt  to  the  Blackboard  bom  KMs  (and  in  aome  cases  vice  versa).  All 
messages  are  put  in  a  mail-box  object  and  processed  sequentially.  These  messages  are  described  below. 

1.  Post  allows  a  KM  to  store  an  object  or  objects  at  the  appropriate  levels  in  the  SBB.  The  syntax  of  post 
is:  (Post  local-object  remote-object  Afile).  where  local-object  is  the  object  or  pointer  to  s  tree  of 
objects  in  a  KM,  remote-object  is  the  level  in  SBB.  file  is  the  name  of  the  file  that  local-object  is 
stt^  in;  the  d  sign  indicates  that  the  file  name  is  optional  and  the  sysie.n  creates  iu  own  name  if  the 
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fihelltoul  -  /bin/trsh 


RESIOXE-CUSS 

SELECT'CUSS 

CREAIE-CUSS 

KME-SUPEIICUSS 

DISPUX-CLASS 

SELECT-SLOT 


:f  L,\7E-;  LPT 


KEMOTE-SLOT 

CIVE-SLOT-TALOE 

SELECT-FACET 

CREATE-FACET 

REMOVE-FACET 

CIVI-FACET-VALUE 

DISPUY-STATUS 

PUSH-PUT 

QUIT 


ROTORE-CLASS 
SELECT-CLASS  ' 
CREATE-CLASS 
HAKE-SUPERCLASS 
D1SPUY-CLAS8 
SEI.ECT-SLOT 
CREATE-SLOT 
REMOTE-SLOT 
CITE-SLOT-TAUIE 
SELECT-FACET 
CREATE-FACET 
RSMOTE-FACEI 


;IVE  F;v-r:  •  ; 


DISFUT-STATUS 

PUSK-FUT 

QUIT 


(•.VALUE  "bullding-r  :DEPTH  0  :CHANGEaBLE  T) 
AS-PARTS  (-.VALUE  NIL  '.DEPTH  0) 

•fining  class  &UILD1 

;j  Warning:  Redefining  MAKE-BUILOl 

rams  Class  /.-BUILDl:  (.-CACHE  ( ;%CUSS  :LINKED-TO-ROOT  :CCWP0 
ENTS  : PARENT  :X  :Y  :SPACX  : POSTED  :M0DIFIED  : DELETED  iHISTOR 
: CURRENT-SOLUTION)  ;IS-A  (HIERARCHY-OBJECT)) 

INKED-TO-ROOT  ( :VALUE  NIL  tOEPTH  2) 

OMPONENTS  ( :VALlff  NIL  :DEP7H  2) 

ARENT  (.VALUE  NIL  :OEPTH  2) 

(:VALUE  NIL  :OEPTH  2  :CHAN6EABLE  T) 

(:VALUE  NIL  :DEPTH  2  ;CHANGEABLE  T) 

PACE  (:VALUE  NIL  :DEPTH  2  :CHANSEABLE  T) 

OSTEO  ( rVALUE  NIL  .-DEPTH  1) 

ODIFIED  (;VALUE  NIL  :DEPTH  1) 

ELETED  (.-VALUE  NIL  :DEPTH  1) 

ISTORY  (:VALUE  NIL  :DEPTH  1) 

URRENT-SOLUTION  (: VALUE  NIL  :OEPTH  1  :POST-IF-SET  (NOTIFY-KM 

)) 

AME  (rVALUE  "bul  1ding-l“  -.DEPTH  0  ;CHANGEABLE  T) 

AS-PARTS  (:VALUE  NIL  ;DEPTH  0) 


ODIFIED 


ISTORY 


-.DEPTH  0  ;  CHANGEABLE  T) 


Figure  9:  Creation  of  Sloes 


■hi-l  limit  -  /tiri/c'-.ii 


Figure  10:  Creation  of  Facets 

file  name  is  not  provided.  As  soon  as  the  Blackboard  receives  the  posted  message  it  accesses  the 


function-block  j  [tower)  [•trim 


appropriate  file  in  the  KM  and  updates  the  SBB.  This  process  is  depicted  in  Figure  12. 

2.  Retrieve  gets  the  information  from  the  SBB  to  a  KM.  The  syntax  of  this  command  is  (Retrieve 
remote-object  dtfile).  If  object  does  not  contain  any  information,  i.e.,  it  has  a  value  nil,  in  the  SBB 
then  the  Blackboard  relays  a  message  across  the  network  to  the  appropriate  KM  that  can  provide  the 
information;  it  is  assumed  that  objects  in  SBB  contain  the  names  of  the  KMs  that  can  update  the 
objects.  The  retrieving  process  is  depicted  in  Figure  13. 


3.  Delete  provides  a  KM  the  ability  to  delete  information  on  the  Blackboard  (SBB).  The  syntax  of  delete 
is  (Deleu  remote-object).  Delete  dots  not  erase  predefined  classes.  Init  only  removes  the  instances. 
This  functioo  is  currently  being  updated. 


Figure  12:  Posting  Infwmation  to  the  Blackboard 


S3  A  Simulation 

A  simulation  of  the  Hyau  Regency  design  process  was  developed  on  two  SUN  computers  to  demonstrate  some  of 
the  capabilities  of  CIDCIS.  The  Blackboard  and  the  Cridc,  Constraint  Manager,  and  Strategic  KMs  exist  on  the  first 
madiine  (Figure  14),  while  the  Connection  Designer  and  the  Structural  Fabricator  KMs  reside  on  the  second 
machine  figure  15;. 

The  deagn-Ekbrication  sequence  is  described  below  and  shown  in  Figures  IS  through  20. 

1.  Connectioo  designer  KM  posts  the  connection  desi^  (denoted  by  1 -rod-connection)  of  the  fourth  floor 
walkway  on  the  Blackboard  (Figure  IS  a). 

2.  Blackboard  receives  the  design  (Figure  16  a  and  b). 

3.  The  connection  object  has  a  method  that  indicates  that  the  connection  design  should  be  checked  by  the 
Critic  KM.  Hence,  the  Blackboard  sends  the  connection  design  to  the  Critic  KM  (Figure  16  c  and  d). 


Figure  13:  Retrieving  Infonnadoo  l^on  the  Blacbovd 

4.  Hie  Critic  XM  replies  that  the  connection  design  is  acceptable^  (Figure  16  e). 

5.  The  Structural  Faluicaior  KM  is  sent  a  message  that  a  connection  design  has  been  completed  and 
needs  fabrication  (Figure  17  a).  The  Fabricaurr  retrieves  the  connection  design,  makes  medications 
and  sends  it  back  U)  the  Blackboard  (Figure  18  a.  Figure  19  a  and  b). 

6.  Blackboard  notifies  the  Strategic  KM  to  check  for  possible  conflicts  (Figure  19  c). 

7.  Strategic  KM  retrieves  the  two  connection  (rod)  designs  (Figure  19  d)  and  sends  it  to  the  Constraint 
Manager  KM  to  check  for  violation  of  inierC^  constrainu  (Figure  19  e). 

8.  Constraint  Manager  KM  notifies  the  Strategic  KM  that  the  designs  are  incompatible  (Figure  19  0- 

9.  Strategic  KM  notifies  this  to  both  the  Connection  Designer  and  the  Structural  Fabricator  (Figure  18  b 
and  c,  Figure  20  a  and  b). 


6  List  of  Publidttions  and  Technical  Presentations 
The  current  project  has  some  unique  features  that  are  not  fully  integrated  in  other  systems.  Some  of  these  features 
wn: 

1.  Object  oriented  Blackboard,  which  acts  as  an  intelligent  datable. 

2.  Distributed  Computing,  where  KMs  reside  in  difleient  computers. 

3.  Heterogeneous  KMs.  where  KMs  may  be  implemented  in  different  programming  environments. 

4.  Negotiation,  where  ctmflicts  between  cooperating  KMs  are  resolved. 

We  feel  that  CIDCIS  will  be  instrumental  in  im|moving  productivity  in  engineering,  reducing  design  eirors. 


ha  the  •enial  d«i|n  tbt  oriiind  cowiecuan  detim  iticlf  wu  fwliy.  bta  we  unane  heic  iKu  ii  is  en  eecepubie  desipi. 
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Fipire  14:  Set  up  for  Simulation  of  the  Hyao  Regency  Design  Problem 
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Figure  18:  Simulaiion  (Continued) 
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increasing  the  detail  to  which  design  is  carried  prior  to  manufacturing  or  construction,  increasing  the  speed  of  the 
design  process,  and  twinging  recognition  of  the  impacts  of  design  decisicxis  on  time,  cost,  and  manufacturability  or 
constructability  back  to  the  designers.  Hence  we  are  making  considerable  effort  to  inesent  our  work  in  various 
conferences.  A  list  of  publications  based  on  this  wodc  is  given  bdow. 

1.  Sriram,  D.,  Logcher,  R.  and  Groleau,  N.,  A  Framework  for  a  Computer  Integrated  Design  and 
Construction  System  International  Conference  on  Computational  Engineering  Science.  Atlanta, 
Georgia,  April  1988  [Invited]. 

2.  Sriram,  D.,  et  al..  Artificial  Intelligence  in  Engineering  Design:  The  M.  1.  T.  Perspective,  Indo-US 
Systems  and  Signals  Wcxkshq),  Bangalore.  India,  January  1988  [Invited]. 

3.  Sriram,  D.,  Blackboard  Architectures  in  Engineering:  Some  Examples,  AAAI  Workshop  on 
Blackboard  Systems,  American  Association  of  Artificial  Intelligence.  Philadelphia,  July  1987. 

In  addition,  the  support  of  ARO  is  also  acknowledged  in  the  fcdlowing  books: 

1.  Tong.  C.  and  Sriram,  D.  (Editors)  Art^icial  Intelligence  Approaches  for  Engineering  Design,  1988 
(Forthcoming). 

2.  Sriram.  D.  (Editor)  Knowledge-Based  Expert  Systems  For  Engineering,  1988  (Forthcoming). 


7  Summary 

The  development  and  testing  of  knowledge  based  computer  tools  for  the  integration  of  design  and  construction 
(CIDCIS)  were  described.  CIDCIS  is  intended  to  provide  coordination  among  multiple  designers  impacts  of  design 
decisions.  It  can  be  envisioned  as  a  netwwk  of  computers  and  users  (called  Knowledge  Modules),  where  the 
communication  and  coordination  is  achieved,  through  a  global  .  the  Blackboard,  by  a  control  mechanism. 

During  the  first  year  of  the  project  our  major  focus  has  been  the  development  of:  1)  utilities  for  defining  the  object 
hierarchy  in  the  Blackboard,  2)  transactions  for  posting,  modif>’ing  and  deleting  infmmation  from  the  Blackboard, 
and  2)  a  simulation  program  to  demonstrate  the  utility  of  CHDDS. 
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